home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Base Documentation 1998 November
/
IRIX 6.5.2 Base Documentation November 1998.img
/
usr
/
share
/
catman
/
u_man
/
cat1
/
collide.z
/
collide
Wrap
Text File
|
1998-10-30
|
5KB
|
133 lines
CCCCOOOOLLLLLLLLIIIIDDDDEEEE((((1111)))) CCCCOOOOLLLLLLLLIIIIDDDDEEEE((((1111))))
NNNNAAAAMMMMEEEE
collide - look for name collisions between libraries
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
ccccoooolllllllliiiiddddeeee [-l] [-d] [-w] _f_i_l_e ...
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
When porting a large application a critical question is ``How do I know
if names in this application conflict with names in libraries I must
use?'' _C_o_l_l_i_d_e answers that question by finding name collisions across
archive libraries and object files. It treats a Dynamic Shared Object
(dso) as if it were an archive library.
Given a list of files, _c_o_l_l_i_d_e finds all duplicate external names and
writes those names to standard output. There is no output if there are
no conflicts.
The ----llll (longform) option adds the object file names to the output; these
are occasionally interesting. This must be the first option to _c_o_l_l_i_d_e
if it is specified at all.
The ----dddd (show duplicates) option reports duplicate external names on
standard error. This reports the same problems _a_r would if run on the
same object files but in more detail. ----dddd applies to object files, not
archive libraries.
The ----wwww (weak symbol) option treats weak symbols the same as normal
external symbols. By default weak symbols are ignored in the search for
duplicates.
The _f_i_l_es named may be either archive libraries or object files. A list
of object files is gathered together (by /_u_s_r/_l_i_b/_c_o_l_l_i_d_e_1) just as is
done by _a_r(1). Gathering of a list of objects stops when an archive name
is seen. Object gathering is important because a _c_o_m_m_o_n declaration may
appear in multiple files yet it does not reflect a name duplication.
_C_o_l_l_i_d_e is a shell script that uses /_u_s_r/_l_i_b/_c_o_l_l_i_d_e_1 to extract the
public symbols from each archive (or gathered collection of objects) and
notes the object file name and archive name along with the symbol. You
may find it useful to find which library or object contains a name, (the
name may be a weak symbol). For example, the following do roughly the
same thing:
/usr/lib/collide1 -w /usr/lib/libc.a | grep strcpy
nm -Bo /usr/lib/libc.a | grep strcpy
If there are too many objects to list them all on the command line, use
the _a_r(1) command to build an archive.
PPPPaaaaggggeeee 1111
CCCCOOOOLLLLLLLLIIIIDDDDEEEE((((1111)))) CCCCOOOOLLLLLLLLIIIIDDDDEEEE((((1111))))
Examples:
cd /usr/lib
collide libgl_s.a libc.a libcps.a /tmp/mylib.a
cd /usr/tmp
# a.o b.o treated as if in archive "none".
# c.o d.o treated as if in a separate archive "none".
collide -d a.o b.o /usr/lib/libc.a c.o d.o
ar cr mylib.a *.o
collide mylib.a /usr/lib/libc.a
# Not useful. All the externals are collisions.
collide libc_s.a libc.a
FFFFIIIILLLLEEEESSSS
/usr/sbin/collide
/usr/lib/collide1
NNNNOOOOTTTTEEEESSSS
The format of a line written by _c_o_l_l_i_d_e_1 is:
variable-name objectfile-name archive-name
Each name is separated by a tab; the line ends with a newline. There are
no blanks or extraneous characters in the output.
If you supply object names to _c_o_l_l_i_d_e it is a good idea to use the ----dddd
option.
While the C language does not have FORTRAN _c_o_m_m_o_n declarations per se,
the declaration int c; will, if it appears outside of any function
declaration be marked in the symbol table as _c_o_m_m_o_n (with Traditional C
only - not with ANSI C).
NNNNOOOOTTTTEEEESSSS
_c_o_m_m_o_n declarations which appear in different archives can cause false
reports of duplications. This should not happen if you put all your
objects in a single archive or list all your objects together on the
command line.
_c_o_l_l_i_d_e recognizes an object as a dso by looking for names ending in ....ssssoooo
or ....ssssoooo....<<<<NNNN>>>> (where <<<<NNNN>>>> is a number, as in ....ssssoooo....1111) so dso's not named that
way are treated as simple object files.
PPPPaaaaggggeeee 2222